Real-time conversations between conversation participants via their computer systems are becoming increasingly common. Such real-time conversations require that the participants be present at their computer systems (e.g., personal digital assistants) and able to respond when a communication is received. A common form of real-time conversation is provided by instant messaging services. An instant messaging service allows participants to send messages and have them received within a second or two by the other participants in the conversation. The receiving participants can then send responsive messages to the other participants in a similar manner. To be effective, a real-time conversation relies on the participants' becoming aware of, reviewing, and responding to received messages very quickly. This quick response is in contrast to conventional electronic mail systems in which the recipients of electronic mail messages respond to messages at their convenience.
Instant messaging services require a networking protocol to establish and manage communications between participants. These services may use various mechanisms to establish sessions, such as a “session initiation protocol” (“SIP”). SIP is an application-layer control protocol that computer systems can use to discover one another and to establish, modify, and terminate sessions. SIP is an Internet proposed standard. Its specification, “RFC 3261,” is available at <http://www.ieff.org/rfc/rfc3261.txt>. A specification for extensions to SIP relating to event notifications, “RFC 3265,” is available at <http://www.ieff.org/rfclrfc3265.txt>. Both of these specifications are incorporated herein in their entirety by reference.
A SIP network comprises entities that can participate in a dialog as a client, server, or both. SIP supports four types of entities: user agent, proxy server, redirect server, and registrar. User agents initiate and terminate sessions by exchanging messages with other SIP entities. A user agent can be a user agent client (“UAC”), which is a device that initiates SIP requests, or a user agent server (“UAS”), which is a device that receives SIP requests and responds to such requests. As examples, “IP-telephones,” personal digital assistants, and any other type of computing device may be user agents. A device can be a UAC in one dialog and a UAS in another, or may change roles during the dialog. A proxy server is an entity that acts as a server to clients and a client to servers. In so doing, proxy servers intercept, interpret, or forward messages between UACs and UASs. A redirect server accepts a SIP request and generates a response directing the UAC that sent the request to contact an alternate network resource. A registrar is a server that accepts registration information from user agents and informs a location service of the received registration information.
SIP supports two message types: requests, which are sent from a UAC to a UAS, and responses, which are sent from a UAS to a UAC when responding to a request. A SIP message is composed of three parts. The first part of a SIP message is a “request line,” which includes fields to indicate a message method (e.g., INVITE) and a request URI that identifies the user or service to which the request is being directed. The second part of a SIP message comprises headers whose values are represented as name-value pairs. The third part of a SIP message is the message's body, which is used to describe the session to be initiated or contain data that relates to the session. Message bodies may appear in requests or responses.
Typical instant messaging services provide a presence service, which can be a SIP registrar, which maintains status information about each user of the instant messaging service. The presence service may also maintain a list of contacts with whom a user frequently communicates. The status information for each user may be represented in the form of a document, called the presence document. An instant messaging user begins using the instant messaging service by registering an endpoint with the presence service. As part of the registration process, the presence service provides the user's contact list to the endpoint. After registration, the endpoint sends periodic updates to the presence service specifying the user's current status, typically by uploading the latest presence document for the user. The endpoint also subscribes to the presence information of each of the user's contacts so that at any time the status of a contact is readily available.
An endpoint typically subscribes to a contact's presence information by sending a SIP SUBSCRIBE request. The SUBSCRIBE request contains headers specifying the contact to subscribe to, the type of event of interest, and the duration of the subscription. For example, an endpoint may subscribe to the presence information of a user's contact by sending a subscribe request to a presence server indicating the contact, an event type of “presence,” and a duration of four hours. The presence server will provide the presence information of that contact initially and whenever it changes, but will stop providing the presence information after the duration ends. The server determines the actual duration using the duration specified by the endpoint as a recommendation. A duration value of zero is reserved for unsubscribing to a particular event, while a missing duration header indicates that the server should use a default value. The server includes the actual duration value that it chooses in the “Expires” header of the response to the SUBSCRIBE request. If the subscription was successful, the response sent from the server contains “200 OK.” When a subscription's duration has nearly ended, the endpoint may send a new SUBSCRIBE request in order to refresh the subscription and ensure that the server does not terminate the subscription. Until the subscription terminates, the presence server sends to the endpoint NOTIFY requests that contain event-specific data whenever an event of the subscribed type occurs. The endpoint will typically respond to the NOTIFY request with “200 OK.” Each NOTIFY request contains a sequence number so that older requests can be distinguished from newer requests and discarded.
In a typical scenario, an endpoint registers with the presence service. The endpoint then sends SUBSCRIBE requests to the presence service for each of the contacts on the user's contact list specifying a non-zero subscription expiration and an event type of “presence.” The presence service sends a response to each request indicating success or failure of the subscription. After a successful subscription, the presence service sends to the endpoint a NOTIFY request containing the current presence document of the subscribed-to contact. The endpoint sends a response to each NOTIFY request indicating success or failure of the notification. Therefore, an endpoint and server exchange four messages for each contact to which a user subscribes: a SUBSCRIBE request, SUBSCRIBE response, NOTIFY request, and NOTIFY response.
It is not uncommon for a user to have many contacts, even 100 or more, or for many endpoints to attempt to register with the instant messaging service at the same time. For example, in one system it is common to see a peak in the number of registration requests around 8 a.m. when many people are arriving at work. A server can quickly become overwhelmed by the quantity of messages and bandwidth consumed by many endpoints registering at the same time. For example, if the endpoints of 1,000 users each having 100 contacts attempt to register at about the same time, the server would have to handle 400,000 messages just to support the initial subscriptions. In addition, as later endpoints register, the presence service needs to provide their updated presence information to the subscribing endpoints. Thus, if 99 endpoints have already subscribed to a user's presence information and an endpoint of the user then registers, the presence information system may send a NOTIFY request to each of the 99 subscribing endpoints, resulting in 198 total messages being exchanged. The high volume of messages limits the number of users that an instant messaging service can support.